Digital content such as application programs and associated data are frequently communicated by service providers to user devices such as digital music players via a network. The user device executes the application programs to obtain a service. For example, the user of a digital music player may subscribe to a fee-based service that allows the user to download one or more digital recordings from a service provider to the user's digital music player. Unauthorized access to data communicated to such user devices, stored on the user devices, or both, may enable unauthorized use of a service, resulting in loss of revenues for the service provider. Such unauthorized access may also result in the disclosure of private user data.
One solution is to embed a cryptographic key in application program code sent to the user device. The application program code itself may also be encrypted with additional cryptographic keys. One-time code obfuscation and part wise decryption may also be applied to the application program code to make reverse engineering difficult. But if the application program code is stored on an unsecured device, it may be subject to long-lasting, extensive attempts to determine its secrets. This susceptibility reduces the effectiveness of the protection mechanisms.
FIG. 1 is a block diagram that illustrates a user device 120 comprising a processor configured to dispatch application program instructions based at least in part on an instruction set with a single opcode value encoding scheme. As shown in FIG. 1, a dispatcher 100 includes an instruction counter 125, an instruction executor 130, and an instruction fetcher 135. Instruction counter 125 maintains a reference to the next instruction to execute in an instruction stream 105 of an executable application program. As shown in FIG. 1, instruction stream 105 is represented as a table of (instruction number 155, opcode value 160) pairs, where the instruction number 155 is an index into the instruction stream 105, and the corresponding opcode value 160 is the opcode value stored at the location referenced by the instruction number 155. A single dispatch table 110 includes a reference 170 to the instruction implementation method 115 (the code that implements the instruction) for each opcode value 165 of instructions in an instruction set. Instruction fetcher 135 receives an opcode value 175 from instruction counter 125 and uses the opcode value 175 to obtain a reference to the corresponding instruction implementation method (150) from dispatch table 110. Instruction fetcher 135 determines the instruction implementation method to execute (150) by performing a table lookup in the dispatch table 110 based at least in part on the opcode value 145 of the instruction. Instruction executor 130 receives an instruction implementation method reference 150 from instruction fetcher 135 and executes the instruction implementation method. Unfortunately, the susceptibility of executable application programs 105 stored on unsecured devices means that an attacker knowing the instruction mapping used by the dispatch table 110 may obtain the executable application program 105. The executable application program 105 may then be executed on a user device controlled by the attacker, thus enabling unauthorized access to or use of a service.
Accordingly, a need exists in the art for a relatively secure way of protecting executable digital content communicated to an unsecured device. A further need exists for such a solution suitable for a resource-constrained device. Yet a further need exists for such a solution that requires relatively little overhead compared to typical public key cryptography systems.